In a dense server environment, multiple computer systems commonly referred to as server blades may each have the ability to access a boot device over a network, e.g., Local Area Network (LAN). A server blade may refer to a typical server that does not include a storage unit, e.g., hard disk drive, Compact Disc Read Only Memory (CD-ROM) drive, floppy disk drive. Since the server blade may not include a storage unit configured to store a boot code image, i.e., binary executable boot code, the server blade may have to be remotely booted such as by a boot device.
Typically, the boot device may implement network boot protocols, e.g., PXE/BIS, iSCSI, that require authentication parameters, e.g., public key, username/password, to be manually installed on the server blades by an administrator in order to remotely boot the server blades. For example, in the BIS protocol, the boot device may generate public/private key pairs where the public key may have to be manually installed on the server blade to be booted. The server blade may then request to receive the boot code image, i.e., binary executed boot code, from the boot device in order to remotely boot. The boot device may then sign the boot code image using a corresponding private key. That is, the boot device may encode the executable boot code using the private key. The boot device may subsequently transmit the signed boot code image to the server blade. The server blade may then decrypt the signed boot code image using the public key manually installed on the server blade.
Since the authentication parameters, e.g., public key, may have to be manually installed on the server blade by an administrator, the boot device may not generate unique public/private key pairs for each network boot operation. That is, in order for the boot device to generate unique public/private key pairs for each network boot operation, the administrator may have to physically visit the device to be booted for each network boot operation to update the authentication parameters, e.g., public key. Because of the time involved in updating the authentication parameters by the administrator, the public/private key pair may typically not be changed for each network boot operation. Consequently, the server blade may remotely boot from the boot device for multiple network boot operations using the same public/private key pair. Accordingly, a security exposure to replay attacks may occur. A replay attack may refer to another server (commonly referred to as a rogue server) intercepting the encrypted boot code image transmitted between the boot device and the server blade to be booted. The rogue server may then re-transmit the encrypted message, which may be outdated, at a later point in time to that server blade and thus gain control of that server blade and be able to direct it to perform unintended operations. The server blade may then boot to the outdated boot code image since the public key decrypts the encrypted boot code image. That is, the server blade may boot to the outdated boot code image since the public/private key pair did not change.
If authentication parameters, e.g., public key, secret key, were configured remotely instead of manually installing them on the server blades, a boot device may be able to generate unique authentication parameter(s), e.g., public/private key pair, secret key, for each network boot operation thereby substantially reducing the exposure to replay attacks.
It would therefore be desirable to remotely configure authentication parameters, e.g., public key, secret key, instead of manually installing them on the devices to be booted thereby being able to generate unique authentication parameter(s), e.g., public/private key pair, secret key, for each network boot operation which may substantially reduce the exposure to replay attacks.